home *** CD-ROM | disk | FTP | other *** search
-
- CURRENT_MEETING_REPORT_
-
- Reported by Donna McMaster/SynOptics
-
- Minutes of IEEE 802.3 Hub MIB Working Group (HUBMIB)
-
- The meeting was called to order at 9:40 a.m. by co-Chairs Donna
- McMaster and Keith McCloghrie.
-
- IEEE Report
-
- Geoff Thompson, Executive Secretary of IEEE 802.3 Repeater Management
- Task Force, reported on the Task Force's status. The IEEE's Repeater
- MIB was approved last September and published last November, and has
- been submitted to ISO where it is undergoing a 30-day CD ballot. A few
- editorial changes are being submitted as comments from the United
- States. The IEEE's MAU MIB has undergone two rounds of balloting and is
- expected to be approved and published by July 1993, and be submitted to
- ISO soon after. The organization of the specification has been changed
- to be protocol-independent with the GDMO-specification in a normative
- Annex. This allows, for example, the sizes of counters to be made
- protocol-specific.
-
- MAU MIB
-
- A message to the mailing-list had questioned the value of mauJabberState
- because that state was so short-lived. The meeting agreed that this was
- not the case since the Jabber state is not exited until reset, and thus
- decided to leave the document as-is.
-
- The question of if and how to represent an interface/port/mau used only
- to manage a repeater was discussed. Normally, these are internal to a
- device and thus often proprietary, and in fact such a MAU might
- effectively be null, in which case there was no need to have MIB objects
- for it. Even if the MAU wasn't null, rpMauType could have an
- enterprise-specific OBJECT IDENTIFIER value. It was agreed to add a
- sentence or two to the Overview section of the MAU MIB to explain this.
- The suggestion to add a diagram to the document was rejected, since it
- was thought the issues were too vendor- specific to be able to reach
- agreement on a diagram.
-
- A suggestion to change the name of mauJabberStateChanges was accepted in
- order to better reflect the behavior of the object, since it only counts
- the times the 'jabber' state is entered, not all state changes.
-
- Repeater MIB
-
- There was lengthy discussion on rptrAddrTrackLastSourceAddress. The MIB
- editors had made a suggestion to the mailing-list prior to the meeting
- to specify that a noSuch error/exception should be returned prior to the
- first frame being received on a port. Responses on the mailing-list had
-
- 1
-
-
-
-
-
- preferred other approaches. All the possible solutions discussed at the
- previous meeting were again listed and discussed at this meeting, with
- the addition of having the object be initialized with the well-known MAC
- address defined for use in FDDI. By a process of elimination, an
- agreement was reached on the solution of deprecating the object and
- defining a replacement which would have a zero-length value until the
- first frame was received on the port.
-
- Other minor changes were agreed to, including:
-
-
- o The nonDisruptiveSelfTest description should be clarified to allow
- returning ``ok'' after doing only a trivial test.
-
- o The setting of rptrReset to cause the Repeater to reset should
- allow the agent to delay the reset (for a short period) if it so
- wishes (e.g., to allow the SNMP Response to be transmitted).
-
-
- At this point, the scheduled time for the Working Group meeting expired.
- Some of the participants left to meet other scheduled commitments, while
- others continued to discuss items informally until 12:30 p.m. In
- addition, a second informal meeting was held from 1:30 p.m. - 3:30 p.m.
- to continue discussion of open issues.
-
- First Informal Meeting
-
- On the topic of having a ``repeater index'' in the MIB, nobody remaining
- in the meeting had much to say. A few implementors thought it might
- make it easier to manage multiple repeaters, but nobody still in the
- meeting wanted to change the MIB.
-
- The requirements for progression to Draft Standard status were reviewed.
- There were at least nine implementations of the MIB represented at the
- meeting. Donna asked the participants if they felt that there was
- enough implementation experience. It was agreed that there was enough
- implementation experience, but perhaps not enough interoperability
- experience.
-
- Bob Stewart observed that all of our implementations of the MIB are of
- agents, but that agents don't interoperate with each other; manager
- implementations are required for interoperability experience. All of
- the agents have interoperated with ``MIB browser'' applications, but no
- known MIB-specific management applications had been written.
-
- The participants agreed that a call should be issued on the mailing list
- for NMS implementors to let the Group know what kind of applications
- they're working on, and what implementation and/or interoperability
- experience they have. Donna and Keith will consider talking to the
- press to publicize the status of the MIB and encourage implementors to
- write applications that utilize the Repeater MIB information.
-
- One person observed that the Group had no multiple instantiation
-
- 2
-
-
-
-
-
- implementation experience. It was pointed out that this wasn't part of
- the Standard.
-
- Dave Perkins questioned whether there was enough operational experience
- with the objects in the MIB. Donna observed that there is considerable
- operational experience with similar objects in enterprise MIBs.
-
- The participants concluded that there was enough experience to move the
- MIB forward as a Draft Standard. Therefore it was decided that the
- editors will make the few agreed-upon changes to the Draft and submit
- the new MIB to the mailing list for three weeks review. If no
- unresolved issues arise on the mailing list in that time, the Draft will
- be forwarded to the IESG.
-
- The same actions and schedule are to apply to the MAU MIB.
-
- Second Informal Meeting
-
- About eight Working Group members met informally to discuss informative
- text that could be added to the Repeater MIB and/or MAU MIB documents to
- help readers understand the implementation options for the repeater
- port(s) through which management packets are transmitted and received.
- The text generated by this group, below, will be included in the next
- Repeater MIB draft, to be reviewed by the Working Group.
-
-
- o Describe ports as sources of traffic into the repeater, with
- examples such as:
-
- - Externally connected devices such as 10BASE-T or AUI.
- - Internal management ports.
- - Backplane internal to implementation.
-
-
- o Some implementations may not manage all of the ports. For managed
- ports, there must be entries in the port table.
-
- o It is the decision of the implementor to select the appropriate
- group(s) in which to place internal ports. GroupCapacity for a
- given group always reflects the number of the number of MANAGED
- ports in that group.
-
- o If some ports are unmanaged such that not all packet sources are
- represented by managed ports, then the sum of the input counters
- for the repeater will not equal the actual output of the repeater.
-
-
- Next Meeting
-
- It was agreed not to hold a meeting during the next IETF meeting in
- Amsterdam.
-
-
- 3
-
-
-
-
-
- Attendees
-
- David Arneson arneson@ctron.com
- David Battle battle@cs.utk.edu
- Andy Bierman abierman@synoptics.com
- Jack Brown jbrown@huachuca-emh8.army.mil
- Jeff Case case@cs.utk.edu
- John Chang changj@ralvm6.vnet.ibm.com
- Shane Dawalt sdawalt@desire.wright.edu
- Manuel Diaz diaz@davidsys.com
- Sandra Durham sdurham@synoptics.com
- David Engel david@ods.com
- John Hopprich hopprich@davidsys.com
- Jeff Hughes jeff@col.hp.com
- Kenneth Key key@cs.utk.edu
- Moshe Kochinski moshek@FibHaifa.com
- Duane Kuang duanek@kalpana.com
- Carl Madison carl@startek.com
- Keith McCloghrie kzm@hls.com
- Evan McGinnis bem@3com.com
- Donna McMaster mcmaster@synoptics.com
- David Perkins dperkins@synoptics.com
- Sam Roberts sroberts@farallon.com
- Dan Romascanu dan@lannet.com
- Rick Royston rick@lsumvs.sncc.lsu.edu
- Paul Serice serice@cos.com
- Chris Shaw cshaw@banyan.com
- Timon Sloane timon@timon.com
- Ira Steckler isteckle@chipcom.com
- Bob Stewart rlstewart@eng.xyplex.com
- Steve Suzuki suzu@fet.com
- Geoffrey Thompson thompson@synoptics.com
- Stephen Tsun snt@3com.com
- Peter Wilson peter_wilson@3com.com
- Kiho Yum kxy@nsd.3com.com
-
-
-
- 4
-